could it extend GenericToolDefinition? then it would reuse type, name and description.

There is no need to mention array - it's already in the definition. Also no need to mention deserialization - it's already explicitly required by a MUST.

This is also consistent with how we define input and output messages.

is it a generic property? I don't see it being used on most tools - https://platform.openai.com/docs/api-reference/responses/create#responses_create-tools, let's not add it as generic?

nit, just more concise rephrasing:

(instrumentations that can't "reliably deserialize and extract the tool definitions" would not populate the attribute at all)

For google-genai it's possible to pass a tool to the model which is just a description of the function and it's parameters, and then in the response the model will say whether and how the application can invoke the function -- see https://googleapis.github.io/python-genai/#manually-declare-and-invoke-a-function-for-function-calling -- i'm wondering if and how we should capture this type of tool definition ?

@DylanRussell Sure, that's the common way to request model with tools definitions. So for instrumentations, I believe we should wrap the LLM invocation and you will capture the tools definitions as the parameters in your decorator.

For example:

# you could wrap this function, and capture 'tools' from 'config' in kwargs
response = client.models.generate_content( 
    model='gemini-2.5-flash',
    contents='What is the weather like in Boston?',
    config=types.GenerateContentConfig(
        tools=[tool],
    ),
)